> I am starting to see the problems.
>
> If I understand correctly, your scenario is this...
>
> REGISTRAR--------PROXY----------NAT---------SIP UA
>
> Can you confirm?

more specifically my scenario is

REGISTRAR/PROXY--------EDGEPROXY----------NAT---------SIP UA


where PROXY is a traditional SIP proxy


> And, since you were talking about scalability, you might also have
> REGISTRAR--------PROXY--------PROXY----------NAT---------SIP UA
>
> is this right?


   About scalability I was thinking about


                         /EDGEPROXY1\
REGISTRAR/PROXY--------            ----------NAT---------SIP UA
                         \EDGEPROXY2/


   So that the UA has flows to EDGEPROXY1 and EDGEPROXY2.


   I have no experience with registrars, I guess that in your case you
have a REGISTRAR/EDGEPROXY in the same process (or group of processes)
and not
REGISTRAR--------EDGEPROXY (linked by other means).

   The problem with the above (separated elements) is that there is not
synchronization about the state of the socket descriptors. As
mentioned before, if the edge proxy crashes the socket descriptors
used immediately after reboot could result in delivering messages to
different flows.

   In my opinion the randomness included in the flow token avoids that
to happen, since after reboot the flowtoken can not be decoded and/or
find an existing flow and that cause the return a error response.
   Then another entry in the registrar binding will be used, i.e. other
flow token. If you have a second edge proxy (that does not crashed at
the same time that the first one :) and the flow token belongs to the
second edge proxy, the message will reach the UA over a flow
previously established to the second edge proxy.



BR

Sergio


Quoting Attila Sipos <attila.sipos@vegastream.com>:

>
>
>>>>>> 3.
>>>>>>> In the Via header's branch parameter, it would encode the
> required
>>>>>>> flow token.
>>>>>>
>>>>>> Here is the issue : From were you get the flow token?
>>>>>> (In my previous email I mentioned 2 options... )
>>>>>>
>>>>
>>>> OK I'm starting to see your problem.
>>>>
>>>> The registration record stores the flow token (obviously)
>>>
>>> It seems that you are integrating the edge proxy and registrar in the
> same code, right?
>
> yes, that's it.
>
>
>>>> And the socket id for the flow would be stored as well (for
>>>
>>> Can you confirm that you call socket id to the socket/file descriptor
> of the connection?
>
> yes.
>
>>>> connection-oriented
>>>> protocols). So if you received a request on that socket, you could
>>>> match that up to one of the registration records and hence, one of
> the
>>>> flow tokens.
>>>>
>>>
>>>  Good approach. I assume that you have available the socket
> descriptor
>>> in the registrar, so basically you consider storing the socket
> descriptor
>>> (number) in the registrar tables. Then perhaps using a flow token it
> is not
>>> necessary since you have available in the socket descriptor all the
> information
>>> that describes a flow (TCP case).
>
> That's true.  I might not need the flow tokens.
>
>
>>>> I hope I have explained how the flow token might be mapped to the
>>>> socket.
>>>
>>>  Yes if my comments above make sense..
>>>
>>>> I can now see that my idea wouldn't work for UDP.
>>>
>>>  Now for UDP perhaps you can consider storing the socket descriptor
> for
>>> UDP and the IP and port for the flow from the NAT.
>
> yes, that would work I think.
>
>
>>>  Furthermore my registrar should not store socket descriptors due
> that
>>> if the edge proxy crashes, the registrar could have a number of
> descriptor
>>> that after the crash belong to other flows.
>>>
>>>  I generate the flow token with REGISTER and send it to the registrar
>>> (other node). The approach works as the draft says for incoming
> requests
>>> (to the Calle). Now when the Callee  sends requests, and the requests
> are
>>> sent over the flow, the responses of that request reach first the edge
> proxy
>>> and it can not forward them to the Callee over the flow, because these
>>> responses don't have the flow token (and the flow token is not stored
> in
>>> the edge proxy)...
>
> I am starting to see the problems.
>
> If I understand correctly, your scenario is this...
>
> REGISTRAR--------PROXY----------NAT---------SIP UA
>
> Can you confirm?
>
> And, since you were talking about scalability, you might also have
> REGISTRAR--------PROXY--------PROXY----------NAT---------SIP UA
>
> is this right?
>
>
>>>> But what if you used the gruu in the contact to match up with the
> gruu
>>>> of a registration?  Then the registration record tells tells you
> about
>>>> the flow token.  That would work wouldn't it?
>>>
>>>  I have not background with gruu. Could you recommend what could I
> read about it?
>
> Sorry, I didn't mean gruu, I was mixing up my drafts!
> I was just looking for a unique identifier for the UA
> which is the sip.instance from the outbound draft (not gruu).
>
>
> Regards,
> Attila
>





_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip